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The method is for securely expanding a storage capacity of 
an IC portable device's memory. For a given data object stored 
or to be stored in the memory of the IC portable device, a unique 
master certificate, used as a descriptor of the data object, is generated 
randomly. The master certificate is indexed in the memory of 
the portable device. A secondary certificate is derived from and 
is determinable only using the master certificate. The data object 
is stored with the secondary certificate on a data storage medium 
external to the portable_device. The memory of the smart card is 
thus freed from the data object and only the IC portable device has 
key information to retrieve the data object stored on the data storage 
medium. 
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WO 00/26866 PCT/CA99/01011 
SECURE MEMORY EXPANSION OF AN IC PORTABLE DEVICE 

FIELD OF THE INVENTION 

The present invention relates to memory management 
processes involving IC portable devices, and more 
particularly to a method of securely expanding a storage 
capacity of a memory of an IC portable device, e.g. a smart 
card . 

BACKGROUND 

Smart cards and other IC portable devices have limited 
memory space/capacity (e.g. 1-8 kb) , often restricted by the 
physical dimensions of the devices and the technology. 
Compression methods have been used to fit more data in a 
given memory space. However, the memory capacity is 
nevertheless reached sooner or later. Other types of memory 
15 storage mediums added on a smart card have also been 
proposed, like optical storage medium, etc. These storage 
mediums require additional circuitry for processing the data 
stored on them, notwithstanding the restrictions, limitations 
or incompatibility caused by the technology. 

Because of the memory limitation of smart cards, they 
are rather generally used as mere personal identification 
devices -to access data on an external mass storage medium, 
with access rights depending on the status of the smart card 
holder. For example, URLs or medical examination numbers may 
be stored in a smart card, thereby providing references to 
externally stored data on a web site, ordinary databank, the 
references and the data being managed by the external 
software applications and not the smart card. As smart cards 
use encryption to secure the data, they are increasingly used 
for financial transactions, where the information to be 



20 



25 



30 



SDOCID: <WO_ 0026866A1 I > 



WO 00/26866 PCT/C A99/01 01 1 

stored in the cards is limited to few numbers and words, if 
any. 

Still, information storage is limited to the memory 
space afforded by the smart card. Thus, the memory limitation 
of smart cards is an obstacle to their use in many fields of 
application where they would be of great use. An example of 
such fields of application is the medical field where the 
large scale implementation of private portable files 
representing the medical history and profile of the patient 
is presently hardly conceivable due to numerous difficulties 
despite the efforts of many to devise solutions. 

A key factor with smart cards is and remains the data 
security. 

SUMMARY 

15 An object of the invention is to provide a method of 

securely expanding a storage capacity of a memory of an IC 
portable device . 

A subsidiary object of the invention is to solve the 
memory limit problem with IC portable devices while 
20 maintaining data privacy even on remote storage site. 

A subsidiary object of the invention is to provide a 
method in which data stored remotely from the IC portable 
device" are linked thereto by indirect, preferably 
unreversably derived relationship, and in which the 
25 references to the data never leave a secure, delimited memory 
zone area distinct from the external medium in which the data 
are remotely stored. 

A subsidiary object of the invention is to provide a 
method by which access authorization to selected remotely 
3 0 stored data can be given to a third party without ever 
endangering the original link privacy of the data with the 
proprietary IC portable device. 
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A subsidiary object of the invention is to provide a 
method by which the data stored externally to the IC portable 
device can be deprived of any character without the IC 
portable device, and can be anonymous and depersonalized. 
5 A subsidiary object of the invention is to provide a 

method by which an IC portable device can generate secure 
virtual memory for its own needs . 

A subsidiary object of the invention is to provide a 
method that preserves the advanced security features provided 
10 by an IC portable device . 

A subsidiary object of the invention is to provide a 
method by which remotely stored data objects are managed 
solely under the control of an IC portable device. 

According to the invention, there is provided a method 
of securely expanding a storage capacity of a memory of an IC 
portable device, comprising the steps of, for a data object 
stored or to be stored in the memory of the IC portable 
device : 

randomly generating a unique master certificate used as 
a reference to the data object; 

indexing the master certificate in the memory of the IC 
portable device; 

deriving a secondary certificate from the master 
certificate, the secondary certificate being determinable 
25 only using the master certificate; 

storing the data object with the secondary certificate 
on a data storage medium external to the IC portable device; 

whereby the memory of the smart card is freed from the 
data object as the data object is stored on the data storage 
medium, thereby securely expanding the storage capacity of 
the memory of the IC portable device as only the IC portable 
device has key information to retrieve the data object stored 
on the data storage medium. 
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According to an aspect of the invention, there is 
provided a method of operating an IC portable device having a 
memory for storing data objects, comprising the steps of: 

detecting a predetermined condition relative to the 
memory of the IC portable device; and 

if the condition is detected, applying the aforesaid 
memory expanding method on a number of the data objects 
stored in the memory of the IC portable device. 

The method according to the invention relies upon IC 
portable device technology to store and manage anonymous 
references to anonymous data located on remote sites (data 
warehouses) . The method allows for the secure storage and use 
(access control) of the information. Only the IC portable 
device carrying the master certificates is capable to locate, 
identify and restore the information stored in an anonymous 
fashion and possibly encrypted in the remote sites. The 
method allows for the secure management of any type of 
information that requires a secure storage and access 
control. The method also allows the device to generate 
virtual memory to meet its needs. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A detailed description of preferred embodiments will be 
given herein below with reference to the following drawings, 
in which like numbers refer to like elements: 

Figure 1 is a schematic diagram showing a system 
suitable for the working of the invention; 

Figure 2 is a flow chart illustrating the method 
according to the invention; 

Figure 3 is a schematic diagram showing a rudimentary 
architecture of a system according to the invention; 

Figure 4 is a schematic diagram showing the conceptual 
organization of a card configured according to the invention; 
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Figure 5 is a flow chart illustrating a representative 
process for reading and writing operations in a system 
according to the invention; 

Figure 6 is a flow chart illustrating details of a 
5 representative writing process according to the invention; 

Figure 7 is a flow chart illustrating details of a 
writing process on a remote database according to the 
invention; 

Figure 8 is a flow chart illustrating details of a data 
10 screening process according to the invention;. 

Figure 9 is a flow chart illustrating details of a 
representative reading process according to the invention; 

Figure 10 is a flow chart illustrating details of a 
reading process on a remote database according to the 
15 invention; 

Figure 11 is a flow chart illustrating a search process 
for a data object stored on a remote database according to 
the invent ion ; 

Figure 12 is a schematic diagram depicting an initial 
20 state of a system according to the invention; 

Figure 13 is a schematic diagram depicting a writing of 
a data object in the card according to the invention; 

Figure 14 is a schematic diagram depicting a writing of 
a data object in a remote database according to the 
2 5 invention; 

Figure 15 is a schematic diagram depicting a writing of 
a data object when a card has insufficient memory space 
according to the invention; 

Figure 16 is a schematic diagram depicting a screening 
30 of data objects in the card according to the invention; 

Figure 17 is a schematic diagram depicting a purge of 
data objects in the card according to the invention; 

Figure 18 is a schematic diagram depicting a reading of 

a data object in a card according to the invention; 

5 
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Figure 19 is a schematic diagram depicting a reading of 
an index in a card according to the invention; 

Figure 20 is a schematic diagram depicting a reading of 
an indexed data object according to the invention; and 
5 Figure 21 is a schematic diagram depicting a reading of 

a data object on a remote database as a result of a forced 
transfer, according to the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
10 Referring to Figure 1, there is shown a schematic 

diagram of a system suitable for the working of the 
invention, which resides in securely expanding a storage 
capacity of a memory of an IC portable device. In the 
illustrated embodiment and the following description, the IC 
15 portable device is a smart card 2. However, it should be 
understood that other types of IC portable devices can be 
used, e.g. a tag, without departing from the invention. The 
system includes a computer 4 provided with a reader 6 for 
communicating with the smart card 2. The computer 4 can be 
20 considered as being on a client side of the system as it 
generates and sends requests to a server 8 according to a 
given protocol, asking for information or action, and the 
server 8 responds thereto. There may be either one 
centralised server or several distributed ones, as 
25 illustrated, interconnected together through a network 10, 
e.g. internet. The reader 6 can be part of a SAM (Secure 
Access Module) providing many functions and features 
especially built for communication and operation with a smart 
card. The SAM may be conveniently designed to perform a 
30 multitasking management of transactions between an 
application software in the computer 4 and the card 2, 
compression/decompression of data, logical access management 
of the physical memory zones on the card 2, in addition to an 
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adaptation to different models of cards via a secured link 
that prevents data misappropriation. 

The usual purpose of the computer 4 / reader 6 / smart 
card 2 arrangement is to manage data stored directly in the 
5 card 2 or in the computer's storage device (e.g. hard disk) 
relative in such a case to reference data stored in the card 
2. Additional resources can be obtained by opening the 
arrangement to the network 10 and servers 8 providing remote 
data storage media 12 to store some or all the data. 
10 However, by operating such a system using conventional 

methods and techniques, the storage capacity of the memory 22 
(see figure 2) of the smart card 2 is nevertheless reached 
sooner or later, or the data stored in the remote storage 
media 12 or the communications between the reader 6 and the 
15 servers 8 are unsecured, or yet the system is subjected to 
other deficiencies. The present invention provides a method 
that solves these and other problems, as it will become 
apparent hereinafter . 

In brief, the method resides in storing data objects 
20 that would otherwise be normally stored in the card 2, on a 
remote storage medium and indexing in the card 2 in a special 
secure manner, the information needed to trace and retrieve 
the data objects. In view of these functions, the card 2 can 
so to- speak be referred to as an index card while the method 

2 5 can be referred to as an indexing method. The method also 

relies upon special processes to manage the storing of data 
objects in the card 2 or on a remote database 12, to transfer 
data objects from the card 2 to the remote database 12 
depending on specific conditions, and to make the data 

3 0 objects stored on the remote server 8 unusable without the 

card 2. These features are all described in detail 
hereinafter. 

Referring to Figure 2, there is shown a flow chart 

illustrating the method according to the invention. The 
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method is applicable either to a data object 14 already 
stored or to be stored in the memory 22 of the IC card 2. In 
the second case, the data object 14 can be stored in the 
memory 22 of the IC card 2 before applying the method, or the 
5 method can simply be applied directly on the data object 14 
to be processed (so it is stored directly in a remote 
database) , which can be advantageous when the data object 14 
is large (it saves time) . As depicted by block 18, the method 
has a step of randomly generating a unique master certificate 
10 16 used as a reference to the data object 14. The certificate 
involved in this step is somewhat analogous to certificates 
found in cryptographic systems in that it can be generated 
using a secret key and other proprietary information in the 
card 2, when it is generated by the card 2. As depicted by 
15 block 20, the master certificate 16 is indexed in the memory 
22 of the IC portable device 2. As depicted by block 26, a 
secondary certificate 24 is derived from the master 
certificate 16, the secondary certificate 24 being 
determinable only using the master certificate 16, or an 
intermediary certificate derived from the master certificate 
L. i ij4C0^ N i6 Thus, the function f x (x) used to derive the secondary^ 
' \ certificate 24 should preferably be a one-way function. As 

^/f~^^p±cted by block 28, the data object 14 is stored with the 
/I secondary certificate 24 on a data storage ^ edium _^°_ ex ^ ernal _ 

to t he IC portable device 2 . / The secondary certificate 24 

~ actsT so to speak as a tag to localize the data object 
provided that the master certificate 16 is used in doing so. 
The data storage medium 3 0 can be provided by one of the 
servers 8 (shown in figure 1) where the data object 14 is 
30 saved in the database 74, 76, 78. The memory 22 of the smart 
card 2 is thus freed from the data object 14 as the data 
object 14 is stored on the data storage medium 12, thereby 
securely expanding the storage capacity of the memory 22 of 
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the card 2 as only the card 2 has key information (i.e. the 
master certificate 16 to compute the secondary certificate 
24) to retrieve the data object 14 stored on the data storage 
medium 12 . 

5 As depicted by block 34, a descriptive label 3 2 can be 

attached to the master certificate 16, the descriptive label 
32 representing a character of the data object 14. In a 
. healthcare application, the descriptive label 32 may relate 
for example to a health care type of service. The purpose of 
10 such a descriptive label 32 is to enable the retrieval of a 
specific type of data objects 14 stored in the data storage 
medium 30 without requiring the retrieval of all of the data 
objects 14 and their analysis to determine whether they 
relate to the desired specific type or not. The descriptive 
15 label 32 is indexed with the master certificate 16 in the 
memory 22 of the card 2 . 

As depicted by block 36, the data ob j ect/^U-Tcan be 
encrypted prior to the storing step (block 28) , the data 
object 14 stored on the data storage medium being thus 
2 0 encrypted. The encryption of the data object 14 is 
particularly desirable if the database used is unsecured, as 
it is the case for common databases. However, other security 
measures can be embodied instead of encryption, some of which 
will Be described hereinafter. 
25 m medical and other applications, it might be desirable 

to provide a way to authorize a third party, e.g. a 
physician, to have access to certain of the data objects, 
e.g. results of tests carried out at a remote site, for a 
given patient who is the holder or owner of the smart card 2. 
3 0 In such instance, as depicted by block 38, there is a step of 
randomly generating a data access authorization certificate 
4 0 derived from the master certificate 16 and with which the 
secondary certificate 24 is determinable. As depicted by 
block 42, the authorization certificate 4 0 is then stored in 
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the IC portable device held by the third party. The data 
access authorization certificate 40 can be generated by an 
appropriate one-way function f 2 (x) applied on the master 
certificate 16. The secondary certificate 24 can then be 
determined by applying another one-way function f 3 (x) using 
the authorization certificate 40. The data object 14 stored 
on the data storage medium 3 0 is thereby retrievable with the 
card of the third party. 

The authorization certificate 40 is preferably 
transmitted to the third party's card via a secured 
communication channel with the card 2 from which the master 
certificate 16 originates, using a cryptographic protocol. 

As depicted by block 44, a trigger 46 can be attached to 
the authorization certificate 40, the trigger 46 carrying 
authorization use instructions regarding the access to the 
data objects, by the third party. For example, the 
instructions may be selected among a life duration of the 
authorization certificate 40 (the certificate can be 
automatically destroyed after a predetermined time period) , a 
service location restriction (to restrict the stations where 
the third party can have access to the data) , a third party 
class restriction (to prevent access to the data for selected 
types of third parties) , and a transitive authorization 
control (to enable the third party to authorize another IC 
card holder to have access to the data) . The concept of 
triggers can be implemented for other tasks, like the 
management of data objects in the card 2. 

A secured microprocessor card server that can be 
embodied in the card reader 6 preferably manages the 
) certificates 24, 40. 

The master and secondary certificates 16, 24, and the 
other certificates like the authorization certificate 40, can 
be generated using a cryptographic algorithm like DES (Data 
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Encryption Standard). Thus the functions f 1 (x), f 2 (x) , f 3 (x) 
can be based on the DES algorithm. Other ways to generate the 
certificates 16, 24, 40 can be used as well. However, the 
certificates 16, 24, 40 must possess certain properties. They 
5 must be unique for a same data storage medium 12 . They must 
be random, so that there is no link between them. They must 
be anonymous, so that they do not provide any known link with 
the card owner. Their binary sequence must be long enough to 
provide an important set of references to avoid attacks based 
10 on the systematic generation of all the binary sequences. The 
certificate generation can be implemented locally in each of 
the cards, or in a centralized fashion relative to the server 
8 providing the data storage medium 12 . 

If locally implemented in the card 2, the certificate 
15 generation process can be integrated to the card's OS (which 
may be virtual in the case where a SAM is used, or even 
distributed among secured resources) . A certificate thus 
originates from the card 2. The difficulty with this approach 
resides in the coordination of the generation of the 
20 certificates between the different cards of the system to 
avoid collisions. For this purpose, a generation primary root 
called primary master certificate can be integrated in each 
card. The root is so to speak analogous to a unique secret 
key. From this point of view, the card 2 uses this root in 
25 the embodiment of a cryptographic derivation device. This 
certificate is qualified as primary master, since all the 
certificates of the card are descendants therefrom. The 
direct descendants can be qualified as secondary master 
certificates. These are the certificates 24 that are 
3 0 generated during a transaction and associated to a data 
object. The secondary master certificates are behind the 
generation of external derived certificates (transient 
certificates that can be used to label temporarily the 
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information in transit or permanent derived certificates like 
the secondary certificates 24 used in the data warehouses 
like those provided by the servers 8) . The primary and 
secondary master certificates preferably never leave the card 
(in its memory or a secured memory zone distinct from the 
data storage medium 12) for security purposes. The 
certificate derivation can be handled in many ways, involving 
additional parameters that can be used to strengthen the 
security of the data eventually stored in the data warehouse 
12, and prevent reverse personalization of the data by usual 
processes . 

In the case of a centralized management of the 

certificates, each data warehouse 12 is preferably provided 

with a certificate generator 84 that coordinates the 

certificate distribution in its reference domain. With this 

approach, there is no certificate lineage notion with respect 

to the primary root of the card 2. Indeed, it is not 

necessary to implement a certificate derivation process that 

coordinates the generation sequence relative to an entire 

index card set to avoid collisions of sequences. However, 

certificate derivation can nevertheless be used to preserve 

the anonymity of the certificates obtained by a card. In this 

sense, there is still a set of certificates that qualify as 

master_certif icates, behind the external certificates. Unlike 

the secondary master certificates of the former approach, 

which are linked by their ascendants, the primary master 

certificate and the master certificates in the later approach 

share no relationships and are absolutely random. This 

feature improves the second criterion associated to the 

certificates (the randomness) , and reinforces the global 

security of the data. Indeed, a central certificate generator 

84 allocates certificates in a random fashion as a function 

of the requests made by the index cards. The allocation of 

certificates by a generator can be achieved according to 

12 
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various strategies, e.g. sequential allocation, random 

selection of certificates in a predetermined set, collision 

with trial and error, etc. In a system with several 

distributed data storage media 12 associated with servers 8, 

each medium 12 can be identified from the others by a unique 

reference domain identifier. The master certificates can then 

be- randomly generated, using the unique reference domain 

identifier, by the central certificate generator 84, and 

transmitted to the card 2 via a secured link. Other master 

certificate generation processes can be used, 

The process of deriving a secondary certificate from the 

primary certificate, as depicted by the block 26, may take 

various forms, depending on the implemented strategy. The 

term "deriving" in this context is not limited to its 

mathematical meaning. It can be any data processing that 

generates an information which originates from the master 

certificate, whose form is also not limited to numerals (it 

can be a word, a number, a phrase, etc.). The secondary 

certificate can be the result of multiple derivation steps 

combined or not with other functions (e.g. hash functions) . 

As an example, let CO be the master certificate. Using a 

predetermined (mathematical) algorithm combined with CO, 

there is obtained a first certificate CI derived from CO. 

Using _the algorithm combined with CI, there is obtained a 

second certificate C2 derived from CI, and so on. If the 

algorithm is a one-way function, then any one of CI to CN can 

be used to provide the secondary certificate. Otherwise, at a 

given stage, a one-way function should be applied to break 

the sequence and prevent reverse derivation that would yield 

back CO from a given CN. By using such a strategy, then an 

intermediate Ci could be stored in a third party 1 s card to 

authorize data access without ever being capable to trace 

back the original certificate CO stored in the user's card, 

thereby maintaining the. system's security. The original 
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derivation sequence can be branched to produce different 
intermediate certificates that can be stored in different 
third parties 1 cards without endangering the data access 
privacy of any one of the third parties as no one could step 
back to then follow the other branch of the sequence of 
another third party. 

As depicted by block 48, the data object 14 can be 
inputted into a secured temporary memory 5 0 provided in the 
card reader 6 or the computer 4, in response to a software 
application request, prior to the generation of the master 
certificate 16 (block 18) . This then starts the secure 
processing of the data object 14 throughout the steps of the 
indexing method. 

Referring to figure 1, the card 2 may comprise a 
database of actions 3 0 in relation with conditions associated 
thereto, and triggers that trigger execution of each action 
for which the associated condition is met. The database of 
actions 30 can be provided in the computer 4, which acts as a 
card server. Triggers are static system objects that initiate 
specific processes on the data objects of the index card 2. A 
trigger may contain a class ID that identifies the object 
class, a directive that specifies the conditions that 
activate the trigger, and a method whose execution is 
initiated by the trigger. The triggers allow for the 
management of certain specific situations or to implement 
particular processes relative to. the data objects of the 
index card 2 in a dynamic fashion, i.e. that have not been 
provided in the basic functions of the card 2. The database 
3 0 may comprise a truth table including the conditions and 
the actions related thereto. 

Referring to figure 2, as depicted by block 50, a 
trigger 52 can be attached to the master certificate 16 
indexed in the memory 22 of the card 2, a predetermined 

action being executed in. relation with the data object 14 
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associated to the master certificate 16 when the trigger 52 
meets a predetermined condition. In addition or 
alternatively, as depicted by block 54, a trigger 56 can be 
attached to the data object 14 stored in the data storage 
5 medium 12, a predetermined action being executed in relation 
with the data object 14 and the master certificate 16 when 
the trigger 56 meets a predetermined condition. The use of 
triggers 52, 56 not only provides additional functions to the 
system, but also enables predetermined time-based operations 

10 on the data objects in an individual manner without requiring 
later complex planning and processing. 

The secondary certificate 24 may correspond to a cell 
address on the data storage medium 12 where the data object 
14 is stored. In a configuration where the data storage 

15 medium 12 comprises information cells managed by a server 8, 
it may then be indexed on the data storage medium 12, with a 
reference (logical address) to the information cell of the 
data storage medium 12 where the data object 14 is stored. 
The data storage medium 12 is then provided with a 

20 concordance table between the secondary certificate 24 and a 
corresponding memory address in the data storage medium 12. 

The data object 14 stored on the data storage medium 12 
may have a structure comprising a pointer to an additional 
data object stored on the data storage medium 12. Such a 

25 feature can be useful for example when the data object 14 is 
an index, or when reorganizing the data objects pertaining to 
a card. 

Referring to figure 1, the system can be designed so 

that the (index) card 2 is operated in specific ways 

3 0 involving the above -described indexing method. For example, 

the system may be designed to detect a predetermined 

condition relative to the memory 22 of the card 2, and if the 

condition is detected, to apply the indexing method on a 

number of the data objects 14 stored in the memory 22 of the 

15 
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card 2. The condition can be for example a saturation of the 
memory 22 of the card 2, in which case the indexing method is 
used to free the card's memory 22 to provide space for 
additional data objects. The detection step can be initiated 
by the card 2 itself when it is docked in the reader 6, or by 
an application software in the computer 4 during the 
processing of the card 2, so that an express request is 
generated to the system to free the memory 22 of the card 2. 

Restrictions on the indexing method can be implemented, 
so that it is executed, for example, only on the data objects 
14 having a mobility property indicating that the data 
objects 14 are moveable outside the memory 22 of the card 2. 
This provides additional functionality and flexibility to the 
system for various applications. In such a case, a mobility 
property is assigned to each data object 14 based on a 
character thereof, the mobility property indicating that the 
data object 14 is moveable outside the memory 22 of the card 
2 or not. The locations of the data objects 14 in the system 
i.e. in a card or in a remote storage medium, can be traced 
by assigning a location attribute to each data object 14, the 
location attribute being set to a resident state for each 
data object 14 stored in the memory 22 of the card 2 and set 
to a non-resident state for each data object 14 stored 
outside, the memory 22 of the card 2, e.g. in the data storage 
medium 12 of one of the servers 8 . 

In addition, an authorized residence period in the card 
2 can be assigned to each data object 14 based ori the 
character thereof . 

The aforesaid features may be used to determine which 

and when object data 14 stored in the memory 22 of the card 2 

should be moved externally and stored in the storage medium 

12, and under which conditions. For example, the indexing 

method can be applied on every data object 14 having the 

location attribute set to the resident state, the mobility 
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property indicating that the data object 14 is moveable, and 
the residence period elapsed when there remains a 
predetermined amount of space in the memory of the card 2. It 
can be applied on a part of any data object 14 having the 
5 location attribute set to the resident state, the mobility 
property indicating that the data object 14 is moveable, and 
regardless of the residence period when the card 2 is short 
or : plans to be short of free memory space. It can also be 
applied on the whole of any data object 14 having the 
10 location attribute set to the resident state regardless of 
the residence period when the card 2 is short of memory to 
carry out an operation. Other conditions may be implemented 
for automatic processing of the data objects as desired. 

A use attribute can be assigned to each data object 14 , 
15 the use attribute being set to an active state when the data- 
object 14 is solicited, an inactive state when the data 
object 14 remains unsolicited for a predetermined time 
period, and an archive state when the data object 14 is 
archived on the data storage medium 12 . The use attribute can 
20 be.... particularly useful in deciding whether a data object 
should be archived or not depending on the degree of use 
thereof. Hence, a frequently requested data object should 
possibly be kept in the memory 22 of the card 2 for fast 
access, _ while an infrequently requested or disused data 
25 object should possibly be stored externally to leave space 
for more .frequently requested data objects, thereby 
increasing the efficiency of the card processing. Thus, each 
data object having the location attribute set to the non- 
resident state and the use attribute set to the inactive 
3 0 state for a predetermined inactive time period is preferably 
archived on the data storage medium 12. The attribute can be 
used by the software application for the automatic 
repatriation of the data objects 14 from the card's memory 22 
or the database 74, 76, 78. 

17 
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The memory 22 of the card 2 may be structured so that it 
comprises non-resident object indexes 58 for storing the 
master certificates 16 of the data objects 14 stored on the 
data storage medium 12, one or several resident object 
indexes 60 for storing the master certificates 16 
(references) related to the data objects 14 having the 
location attribute set to the resident state yet that are or 
have been subjected to a forced indexing, a master index 62 
for storing a unique key identifier of the card 2, and a 
class index 64 for storing a list of classes of the data 
objects subjected to a forced indexing. The memory 22 of the 
card 2 may also comprise an index 6 6 for storing references 
to nominative files located in remote sites. 

The non-resident object indexes 58 may be considered as 
data objects 14 to which the indexing method is also 
applicable. Likewise, each master certificate 16 may be a 
data object 14 to which the indexing method is also 
applicable . 

The IC portable device may be provided with an object 
dictionary 68 containing object class definitions including 
directives and methods for the data objects 14. Each data 
object 14 may then be classified in relation with the 
definitions in the object dictionary 68. The class 
definitions may include a priority qualifier determining a 
data object indexation priority order for applying the 
indexing method. 

The functional blocks shown in figure 1 represent 

functional devices of the system for carrying out the 

indexing method according to the invention, and the arrows 

and rings indicate where the devices can be located as the 

system may take many configurations. For example, the device 

executing the indexing, namely the indexing device 70, can be 

integrated entirely into the operating system (OS) of the 

smart card 2 or, alternatively, entirely in the reader 6 (or 
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a SAM) or in the memory 72 of the computer 4, or distributed 
through these devices. The advantage of integrating the 
indexing device 70 in the OS of the smart card 2 is that it 
allows for the secure processing (management of the anonymous 
5 references) associated to the master certificates and the 
transactions. With the master certificates so remaining 
always in the card 2, a third party (a person or a computer 
system) is prevented from catching and using them. The 
indexing device 70 fulfils mainly two functions: the 

10 management of non-resident data objects, i.e. those whose 
displacement to a remote site is predetermined; and the 
virtual memory generation for the card 2, i.e. the forced 
displacement of objects that normally reside by definition in 
the card 2. The card's OS decides this displacement. If the 

15 reader 6 is provided with a SAM, the indexing device 70 can 
be integrated into a software layer of the SAM. With a SAM, 
the OS of the card 2 is distributed in a client/server 
fashion, the server portion residing in the SAM while the 
client portion residing in the card 2. The indexing device 70 

2 0 can even be embodied in the computer 4, so long as it is 

secured properly. In such a case, the computer 4 can be used 
to emulate a virtual IC card. 

The database provided by the storage medium 12 can take 
various^ forms, like an anonymous database 74, a 
25 depersonalized database 76, or a cryptographic database 78. A 
distinctive feature of the data objects stored in these 
information warehouses resides in the data being anonymous 
and optionally encrypted. The personalization of the 
information (and optionally the decryption) , as well as the 

3 0 access control, mainly achieved by the identification of a 

given data object in the database 74, 76, 78, must 
necessarily involve the use of a card holding the proper 
references (certificates) . 
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The indexed objects can be referenced in many ways, 
using a reference system 80. A reference may correspond to a 
group of distinct objects (several basic information cells) 
or gathered together (a cell containing several objects) . An 
open (episodic) reference can also be used, i.e. whose 
corresponding objects have the property of being capable to 
evolve or be linked to other objects gathered under the same 
cell (conversely, it can be said that there are several types 
of cells in the database) . 

The card 2 contains indexes that contain the references 
or certificates, thereby forming an index system 82. An index 
can be associated to a class of objects or yet be global and 
containing references to several object classes. Some indexes 
can be public, i.e. whose content is accessible to the world 
outside the card 2, while other indexes can be system indexes 
only accessible by the OS of the card 2. 

As previously indicated, a reference generator device 84 
generates the references. The references must be unique, 
random (no links between them) , anonymous (no links with the 
card holder) , and have sufficiently long binary sequences to 
obtain an important referential set to resist to their 
analysis. The references can be generated using a central 
random reference generator located in a server 8, or by 
derivation from a master certificate indexed in the card 2. 

The use of the references can be managed by a manager 
device 86 for this purpose. The references to an object can 
be handled by different cards that have received 
authorization to do so by the acquisition of a copy of a 
reference or a reference derived from the original. The rules 
of use of the references (aspects of time, function, 
delegation of rights, transitivity, deletion, limits and 
scope of the authorizations, etc.) must be handled by a 
process or a function of the IC card that manages and applies 
these rules. 
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The system may be provided with an anonymous 
backup/restore device 8 8 that can be invoked whenever a user 
looses its card or the card becomes defective for any 
reasons. 

5 The . computer 4 executes one or several software 

applications providing the tools and functions that are 
relevant to the system's purpose, e.g. a medical application 
if the kind of data objects to manage with the system is of a 
medical nature. An example of an already existing software 
10 application used in the medical field is Medicarte™, which is 
a medical software for the management of computerised patient 
records. In a medical context, the smart card 2 has a double 
function and a double purpose. It may act as a portable 
medical record of a patient, and contains medical and 
15 administrative data in its memory. In such a case, it is also 
used so to speak as an access key to the patient record on a 
server 8. It contains encryption keys in its memory, which 
allow for the gathering of the content of the patient record 
and makes it accessible when the patient receives health care 
20 services. It may also act as a professional user card, given 
to a medical practitioner for the management of accesses to 
the network 10 or to patient records stored in the servers 8. 
In such a case, the professional user card may hold a digital 
signature so that the health care professional's name can be 
2 5 linked to each new entry or transaction. 

Features found in cryptosystems and networking systems 
can be implemented in the system according to the invention. 
For example, authentication processes can be implemented 
either at the level of the card holder (e.g. password) or the 
30 card itself (e.g. digital signature). Mechanisms regarding 
access rights, non repudiation, data integrity, encryption, 
are other examples of features that can be implemented in the 
system. 

21 
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All data are preferably encrypted before being 

transferred. A public key cryptosystem can be used for this 

purpose. The encryption keys are stored in the card's memory 

(patient or professional card) and should never leave the 

5 card. They can therefore neither be copied, nor be 

intercepted on the network. These encryption keys are used to 

protect new data entered by a user and that must be 

transferred on the network 10 and stored in the servers 8. 

Should a non-authorized person intercept the data during a 

10 reverse transfer (from a server's database 16 to a user), 

he/she will not possess the necessary keys to decrypt the 

message. A diary of transactions may be used to keep a list 

of all the activities carried out on the network 10. The 

corrections made in a patient record, the entry of new data 

15 and even the simple consultation of data may be logged in the 

diary. The physical protection of data at the storage 

location requires various security mechanisms. Of course, it 

is recommended to ensure the minimum physical protection of 

the databases. To complete this protection, the system relies 

2 0 on a special recording system, where all information is 

recorded anonymously, it is therefore impossible to find the 

identity of a patient from clinical information. Also, the 

clinical data of the same patient record is preferably not 

grouped _ together in the database 16. Therefore, it does not 

25 contain any common identifier that could allow a link to be 

built up between the -data. The patient record is thus in fact 

a virtual record, which is reconstructed safely when the 

patient presents his/her card to an authenticated health care 

professional. In the recording system, all clinical data 

contained in the patient records may also be automatically 

copied into a depersonalised database 70. This database does 

not contain any information on the identity of the patients. 

On the other hand, the clinical data thus grouped together by 

patient, makes it useful for statistical analysis on the 
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population's state of health or for the evaluation of health 
costs. The system therefore offers to health service managers 
a vast database that is immediately available at no 
additional cost, yet which has no effects on the data privacy 
and security. 

Referring to figure 3, there is shown a schematic 
diagram illustrating a possible architecture of the system in 
a functional point of view. The anonymous database functions 
9 0 manage the anonymous data warehouse, and provide local 
security of the data. The emitting functions 92 are for the 
structuring of the file, the definition of the security of 
the data and the access rights. The backup database functions 
94 manage the backing up and the restoring of the references 
(certificates) of the index cards. The application 96 
performs a semantic management of the information. The API 
(Application Program Interface) 98 sees to the formatting of 
the application and network data, the network connection, the 
optimization of the processes (cache, multitasking, etc.), 
and the security outside the card. The index card's OS 99 
sees to the data access control, the index and reference 
management, the indexed data management, the virtual memory 
management, the shared data control, the critical data 
security, the data anonymity management and the data backup 
production. 

Figure 4 is a diagram showing an example of object 

classes for the index card IC. The objects of the index card 

IC are grouped in two metaclasses: the system objects SYSJDBJ 

and the public objects PUB_OBJ. The public objects are 

accessible to the world outside the index card IC. These are 

generally the data objects accessible to the normal actors in 

the system (e.g. patient, physician). The system objects are 

objects that are not- accessible to the world outside the card 

IC. These objects are under the unique management (creation, 

update, etc.) of the card's OS. The objects of the card IC 
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may have a visibility property that is different whether the 
object is a public or system object. The visible public 
objects have no operation restrictions (read, write, etc.) 
insofar as the requesting party has the proper access rights 
for the objects. The non-visible public objects are not 
accessible by the normal actors in the system. These objects 
remain in the card IC and are considered by the card IC as 
being non existent. The visibility property is controlled by 
the actors owning the pre-established authorizations. The 
visible system objects are management objects accessible in 
read-only mode to the system- s actors, insofar as they have 
the proper access rights. For example, the dictionary of the 
card's objects is a visible object. The non-visible system 
objects are management objects that are not accessible to the 
world outside the card IC. For example, the data structures 
used by the card IC for the management of the card's virtual 
memory is a non-visible system object. 

The public objects are divided into two classes: the 
data objects DATA_OBJ and the management objects MANAG_OBJ. 
The data objects are subdivided into three classes: the 
resident objects RES_OBJ, the non-resident objects NR_OBJ and 
the hybrid objects HYB_OBJ. A resident object is stored in 
the card IC while a non-resident object is stored outside the 
card IC_, on an external storage medium. Some objects may 
intrinsically be never written in the card IC, like those 
whose size exceeds the card's memory capacity. The definition 
of the objects belonging to these three classes depends on 
the application field. These objects are formed of primary or 
complex objects. A primary object is a data atom and it does 
not contain any other object. A complex object is formed of 
several primary or complex objects. For a medical card, 
objects like as follows could be found: objects for the 
management of the diagnostics DIAG_MED, prescriptions 

PRES_MED, laboratory examinations BLOOD_FORM , URINE_EXAM 
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etc. The management objects cover a set of public objects 
predefined for the data management. There can be found, among 
other things, DATE_OBJ for dating transactions, SIGNATURE_OBJ 
for signing transactions, VER_OBJ for indicating the version 
5 of an object, CLASS__ID for identifying an object class, etc. 

The system objects are all management objects. Among 
them, there can be found objects for the management of 
indexed objects INDX_OBJ, non-resident object indexes 
INDX_NR_OBJ, a resident object index INDX_VIRT_RES_OBJ, a 
10 class index INDX_CLASS_OBJ and a master index 
INDX_VIRT_MASTER_OBJ. There can be found also an object 
dictionary DICT_OBJ and a trigger management object 
TRIGGERJDBJ. 

Resident objects are complex data objects of the public 

15 domain. They belong to the RES_OBJ class and are stored on 
the card IC. These objects are generally dynamic, i.e. they 
can be moved on an external memory to provide the space 
needed by the card IC. Their indexing priority is defined in 
the object dictionary DICT_OBJ. 

20 A resident object contains the following primary or 

complex objects: PRIMJDBJ which is a primary object and/or 
COMPJDBJ which is a complex object containing the user data 
!a resident object may contain several objects) ; DATE_OBJ 
which is the recording date of the resident object; and 

25 SIGNATURE_OBJ which is the electronic signature of the party 
who stored the resident object. 

From the standpoint of the user, the non-resident 
objects are public objects belonging to the NR_OBJ class. 
They are complex or primary data objects stored in an 

3 0 external memory of the index card IC. It can be any type of 
memory (see figure 1) . In every case, the public object is 
encapsulated in a system object belonging to the class 
SYS NR OBJ. 
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A non-resident object stored in an anonymous database 
BDA 74 (as shown in figure 1) is encapsulated in a system 
object of the SYS_NR_BDA class. It contains the following 
objects: CERTIFICAT_SELEC which is an object referring to an 
indexed object (it is a selective certificate which allows 
for the selection of a particular object) ; and CRYPT OBJ 
which is an object containing a cryptogram. By removing the 
cryptographic capsule, a public complex object of the class 
NR_OBJ is obtained. This object is formed of the following 
objects: CLASS_ID which is a public primary object 
identifying the class to which the non-resident object 
belongs (subclass of NR_OBJ) ; VER_OBJ which is a public 
primary object identifying the object's version; PRIM OBJ 
which is a primary object and/or COMP_OBJ which is a complex 
object that contains the user data; DATE_OBJ which is the 
recording date of the object; and S I GNATURE_OB J which is the 
electronic signature of the party who stored the object in 
the database. 

The non-resident objects of a depersonalised database 
BDD 76 (as shown in figure 1) are, originally, defined and 
managed in the same way as the objects of an anonymous 
database BDA. However, there are differences at the level of 
the object encapsulation that belongs to the SYS_NR_BDD 
class. Indeed, unlike objects of a BDA, the certificate is a 
primary object belonging to the class CERTIFICAT_IC . The 
certificate is the same for all the objects belonging to a 
same holder. There are thus no selective certificates. 
Indeed, the primary goal of a BDD is to allow for the 
anonymous exploitation of data in an administrative, 
statistical or search point of view. 

The non-resident objects of a cryptographic database BDC 

78 (as shown in figure 1) are, somewhat, an aggregation of 

the system objects of a BDA and of a BDD. Indeed, the 

encapsulation, object belonging to the SYS_NR_BDC contains a 
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certificate of the class CERTIFICAT_IC, that refers to the 
entire data of a card as well as a selective certificate of 
the class CERTIFICAT_SELEC allowing a particular object to be 
located among the objects of a holder. The CERTIFICAT IC 
5 allows for the retrieving of all the objects of a card, while 
the r CERTIFICAT__SELEC allows for the selection of a specific 
object . 

The non-resident object index is a dynamic system 
management object. Indeed, the size of the indexes may 
10 increase importantly as a function of the transactions 
achieved. It can thus be screened or simply entirely moved on 
an external memory. The non-resident object index belongs to 
the class INDX_OBJ_NR and contains references to data objects 
residing in the external memory. It may be a BDA or BDC type 
15 of memory. The BDD type of memory is not used for 
transactional operations; there is thus no index referring to 
specific objects. The index card IC yet keeps the global 
reference CERTIFICAT_IC to all of its BDD objects. In the 
case of a non-resident object index referring to objects on a 
BDA, the index belongs to the class INDX_OB J_NR_BDA and 
contains the following objects: CERTI F I CAT_SELEC which is the 
reference of the indexed object on the BDA (it is a selective 
certificate); DESCRIP_INDX which is a possibly complex object 
of the_ public class RES_OBJ, which corresponds to the 
descriptors of the transaction (this object belongs to a 
resident class since it is saved in the index card) ; 
ADDRESS_XMEM which is the logical address of the BDA; 
DATE_OBJ which is the creation date of the non-resident 
object certificate; and S I GNATURE_OB J which is the electronic 
signature of the party from who the non-resident object 
certificate originates . 

Every non-resident object index can be merged into a 
single one, taking into account the access rights to the 
various objects. 
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A non-resident object index referring to objects of a 
BDC is an object belonging to the. class INDX_OBJ_NR. It thus 
contains the same basic objects as an index referring to a 
BDA. However, there are differences at the referential level. 
Indeed, a BDC uses two reference certificates: the generic 
referential of the index card, CERTIFICAT_IC, and a selective 
certificate of the class CERT I F I CAT_SELEC . To manage the 
objects of a BDC, the index card IC thus uses a complex 
object INDX_OBJ_NR that contains the following objects: 
DESCRIP which is a primary or complex object of the public 
class; RES_OBJ which corresponds to the descriptors of the 
transaction (formal data) ; ADDRE S S_XMEM which is the logical 
address of the BDC; DATE_OBJ which is the creation date of 
the non-resident object certificate; SIGNATURE which is the 
electronic signature of the party from who the non-resident 
object certificate originates; and the object INDX_IC which 
contains the primary object CERTIFICAT_IC which is the card's 
reference . 

The index of the virtual card memory (VCM) is a static 

system management object. It is an index of dynamic resident 

objects, it contains the references to objects that are 

stored in the card IC, but that have been subjected to a 

forced indexing (mechanism of the card IC activated to 

provide, memory space in certain circumstances) . The 

referenced objects can originate from non-resident object 

indexes or be resident data objects. A card IC contains a 

single VCM index. It contains the following primary objects: 

CLASS_ID which identifies a class of objects (it may be a 

subclass of the IC or of the IC class) ; NBR_OBJ_INDEXES which 

provides the number of indexed objects for an object class or 

for the whole IC according to the object CLASS_ID; TYPE VCM 

which provides the kind of an indexed object: a class or a 

class object; ADDRESS_XMEM which is the logical address of 

the external memory (data warehouse) for reference; and 
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CERTIFICAT_VCM which is the referential in the external 
memory . 

In the case where the class identifier CLASS_OBJ is a 
subclass of the card IC, if the object TYPE_VCM defines an 
object class, NBR_OBJ_INDEXES is set to 1 and the certificate 
points on the entirely indexed class. However, if TYPE VCM 
specifies an object, then NBR_OBJ_INDEXES corresponds to the 
number of occurrences of indexed objects of the class and 
CERTIFICAT refers to a subset of objects of the class. 

In the case where the class identifier is the object IC, 
NBR_OBJ_INDEXES then indicates the number of indexed classes 
and the certificate refers to a set of object classes. The 
number of referred classes is indicated by the object 
NBR_OB J_INDEXES . In this case, the card's OS uses the object 
INDX_CLASS to recognize the identity of the indexed classes. 

The card's master index is a static system object 
belonging to the class INDX_IC. It is the highest -level 
index. Its scope covers the whole card IC. It contains the 
object CERTIFICAT_IC that identifies anonymously an index 
card IC. It is used, among other things, as a referential on 
a BDD and a BDC. 

The class index INDX_CLASS is a static system object. It 
contains the list of the object classes subjected to a forced 
indexing. It is constituted by the primary object CLASS_ID 
that identifies an indexed object class. 

The nominative site reference index is a non-mobile 

(static) public object belonging to the class INDX_NOMIN. 

This index is different from the other card's indexes. 

Indeed, it is first a public object and not a system object, 

which means that it is managed at the application level. It 

refers to nominative files located in remote sites. Due to 

his nominative character, it is allotted a static object 

property, which means that it is never indexed outside the 

card IC. In the medical field, this index is formed by the 
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patient index INDEX_JPATIENT. It contains the following 
objects: SITE which identifies a point of service where a 
nominative file is located; SUPPORT_DOS which identifies the 
medium on which the file is recorded, i.e. paper or 
electronic (CD-ROM, hard disk, magnetic tape, etc.); FILE_ID 
which is the file identifier; and ADDRESS which is an access 
reference to the file, e.g. telephone number, addresses, etc. 

The card's object dictionary is a static system object 
belonging to the class DICT_OBJ. It contains the description 
of the object classes existing in the card. It is formed of 
the following objects: CLASS_ID which is a primary object 
identifying an object class; PROP_OBJ which is a complex 
object specifying the properties of the objects of the class, 
e.g. domain, visibility, residence (number of days of 
residence), mobility (indexing priority), etc.; INC_OBJ which 
is a complex object indicating if the objects of the class 
are indexes, resident objects or non-resident objects and, 
depending on the case, identifies the links to be established 
with other objects. 

Triggers are static system objects belonging to the 
class TRIGGER_OBJ. The triggers launch process methods on the 
card's objects. A trigger contains the following objects: 
CLASS_ID, which identifies an object class; DIRECTIVE, which 
specifies the triggering conditions of the trigger; and 
METHOD, which is the method, launched by the trigger. 

The triggers allow to manage certain specific situations 
or to implement particular processes on the card's objects in 
a dynamic fashion, i.e. which are not intended in the basic 
functionality of the card IC. 

Referring to figure l, the indexing process may be 
carried out in a three-level fashion. The first indexing 
level of the card 2 is initiated by the non-resident object 
indexes 58. These indexes 58 contain the selective 

certificates that refer to objects stored in the external 
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memory 12. Whatever is the type of the external memory 12, 
only the .selective pointer is used at a transactional level. 

The second indexing level is a mechanism that allows the 
card 2 to achieve an automatic screening of the data objects 
5 so as to keep only the most recent (or active) ones in the 
internal memory of the card 2 and, in this way, to provide 
the additional memory space in the card 2. The card 2 
triggers the indexing when an object exceeds its number of 
authorized residence days as indicated in the object 

10 dictionary 68. In the case where a data screening is 
effective on all the objects of the card 2 and that the need 
of space is still present, the card 2 may index active 
objects on its external memory 12. It is then a forced 
indexing. It is a first level of virtual memory generation. 

15 To meet the memory space needs, the card 2 has a more 

drastic means: the integral indexing of the objects. The 
objects are then entirely indexed on the external memory 12 
of the card 2. It is a third indexing level and a second 
level of virtual memory generation that allows the card 2 to 

20 allocate additional space. 

The card 2 can only index resident objects having the 
property of being mobile (dynamic), as defined in the object 
dictionary 68. The index card 2 takes the priority of an 
object _into account (defined in the object dictionary 68) to 

2 5 determine the data indexing order. The priority may determine 
the relative importance of an object with respect to other 
objects of the card 2 or be qualified as a function of other 
strategies. The card can also apply different strategies 
based, for example, on an empirical analysis of the rate of 

30 use of the objects. 

The static objects cannot be moved on the external 

memory 12. Thus, the more the card's objects are qualified as 

dynamic, the more the card 2 has the potential for generating 

virtual memory. However, the card 2 must manage the memory 
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efficiently to avoid too frequent accesses to the external 
memory 12 that could slow the system. 

Referring, to figure 5, there is shown a flow chart 
illustrating an example of a general process executed by the 
system with the indexing process as herein above described, 
for reading and writing operations. Additional operations of 
various types can be of course also implemented. 

As depicted by the block 100, a request is generated by 
the software application in the computer 4 (shown in figure 
1) . As depicted by the block 102, the request is transmitted 
to the reader 6, according to a pre-established protocol, 
which redirects it to the operating system (OS) of the card 2 
as depicted by the block 104 . The card 2 can receive a set of 
requests, like reading and writing requests, as depicted by 
the block 106. As depicted by the block 108, the card 2 
determines the type of the requested operation, and performs 
the corresponding procedure, like the one for writing a data 
object as depicted by the block 110 or the one for reading a 
data object as depicted by the block 112. In the case of a 
writing operation, the application receives an 

acknowledgement once the procedure is completed, as depicted 
by the block 114. In the case of a reading operation, the 
application receives the resulting data object, as depicted 
by the block 116. The application then determines whether the 
data object is an index as depicted by the block 118, and if 
so, verifies whether the application needs the indexed data 
objects as depicted by the block 12 0. In such a case, then 
the data objects to be retrieved from the memory are selected 
as depicted by the block 122, and a new request is prepared 
for the retrieval of the information (block 100) . In the case 
where the data object is not an index or that the application 
does not need a data object in an index, then the data object 
can be processed by the application as depicted by the block 
124 . 
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Referring to figure 6, a writing request may involve the 
writing of data objects in the card 2 (resident data 
objects) , in which case the process branches on the right- 
hand side of the block 124. Otherwise, the procedure for 
writing data objects on a remote database 12 is initiated, as 
depicted by the block 126. 

Referring to figure 7, the writing of non-resident data 
objects on a remote database 12 involves the creation of an 
index and a data entry (certificate address of the database, 
etc.) for this index in the card 2, as depicted by the block 
128. The creation and the management of the indexes are under 
the unique control of the card's OS, not the application. 

Referring back to figure 6, a lack of memory space 
resulting from the writing request of an object in the card 2 
may trigger a procedure for screening the objects in the card 
2, for forcing transfer of the objects in the card 2 to the 
database 12, or for directly indexing the data object which 
is, the subject of the request into the database, as depicted 
by the steps on the left-hand side branch of the block 130. 
The incompatibility of the size of an object with the free 
memory space of the card 2 may also cause the indexing of the 
object on the database 12, as depicted by the steps on the 
left-hand side branch of the block 132. Any indexing of data 
objects, on the database 12 must take the mobility property of 
the objects into account. An object defined as being non 
mobile cannot be indexed. The management of the virtual 
memory is achieved through the system index INDX_VCM as shown 
in figure 4. Of course, other types of implementations are 
possible. 

Referring to figure 8, there is shown representative 
seeps that can be executed in a screening process depicted by 
zhe block 134 in figure 6. 

Referring to figure 9, a reading request may involve the 

reading of a resident object, in which case the process 
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branches on the right-hand side of the block 136. A resident 
object can be a final data object or an applicative index 
(index accessible to applications) . 

Referring to figure 10, during the reading of an index, 
the random anonymous references (master certificates) are 
replaced by sequential numbers to maintain their 
confidentiality, as depicted by the block 138. Likewise, the 
addresses of the database 12 are masked, as depicted by the 
block 140. 

For reading a non-resident object, the applications must 
first read the corresponding index as depicted by the block 
14 2 and then, by means of the sequential numbers contained in 
the index entries, select the indexed data objects to be 
retrieved (step 122 of figure 5) . This process corresponds to 
a specific and descriptive implementation of the indexing 
device 70. Other types of implementations are possible. 

Figure 11 shows representative steps involved in a 
process for retrieving an object in a database 12, as 
depicted by the block 144 of figure 10. 

Referring to figure 12, there is shown a schematic 
diagram illustrating an initial state of the memory card 2 
and its virtual memory index 150, and the external auxiliary 
memory 12 with the database 74 . 

Referring to figure 13, there is shown a schematic 
diagram illustrating a writing operation for a resident data 
object, when the card 2 has enough free memory space. The 
application 152 transmits a writing request 154 to the card 2 
that simply stores the data object 14 in its memory 22. 

Referring to figure 14, there is shown a schematic 
diagram for a writing operation when the card 2 has not 
enough memory space and the object can be indexed. The 
application 152 transmits the same request as in figure 13, 
but the card 2 generates a reference 154 (master certificate!, 
and stores it in the virtual memory index 150./' The data 
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object 14 is transmitted to the external auxiliary memory 12 
and stored in the database 74 . 

Referring to figure 15, there is shown a schematic 
diagram illustrating a writing operation for a non-resident 
5 data object. The application 152 transmits a writing request 
156 in this respect to the card 2 that generates a reference 
154 (master certificate) for the object and stores it in an 
applicative index 160. The data object 14 is then stored in 
the database 74 of the external auxiliary memory 12 by the 
10 card 2. 

Referring to figure 16, there is shown a schematic 
diagram illustrating a writing operation when the card 2 has 
not enough memory space and the data objects in the card 2 
can be indexed. As a result, the data objects in the card 2 
15 are screened and sent to the database 74 of the external 
auxiliary memory 12. This process recovers memory space in 
the card 2 to allow for example the execution of a requested 
operation. Upon the request 156 from the application 152, 
portions of the virtual memory index 158, the applicative 
index 160 and the resident object 162 are transferred and 
stored into the database 74 of the external auxiliary memory 
12. References 163 (master certificates) to the transferred, 
portions are stored in the resident part of the virtual 
memory jLndex 15 0. 

25 Referring to figure 17, there is shown a schematic 

diagram illustrating a process similar to the process of 
figure 16, where the objects and the applicative index are 
transferred entirely to the database 74 and indexed in the 
virtual memory index 150 of the card 2 using a single master 

30 certificate 165. 

Referring to figure 18, there is shown a schematic 
diagram illustrating a reading operation when the requested 
object 14 is not an index and is located in the card 2 . As a 

result, the object 14 is simply transmitted to the 
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application 152 in response to the request 158 in this 
respect . 

Referring to figure 19, there is shown a schematic 
diagram illustrating a reading operation when the requested 
object is an index 160 and is located in the card 2. As a 
result, the references (master certificates) in the 
applicative index 16 0 are replaced by sequential numbers and 
the database addresses are masked. The card 2 transmits thus 
a modified applicative index 168 to the application 152 in 
response to the request 162 in this respect. 

Referring to figure 20, there is shown a schematic 
diagram illustrating a reading operation where an indexed 
non-resident object 170 is identified by the information 
providing from an index entry 164 in the applicative index 
160 located in the card 2 . As a result, the object 170 is 
found in the database 74 from the index entry 164 transmitted 
from the application 152 to the card 2, and transmitted to 
the application 152. 

Referring to figure 21, there is shown a schematic 
diagram illustrating a reading operation where an object 14 
has been transferred out of the card 2 to the database 74 as 
a result of a former lack of memory space. The object 14 is 
found back in the database 74 through the virtual memory 
management index 150 of the card 2 . 

The following description provides a typical scenario 
where the indexing device 70 is used for the management of 
data objects in a healthcare system, .where a patient consults 
a healthcare practitioner. Referring to figure l, both 
parties insert their respective cards in the card reader 6. 
The healthcare practitioner needs to save information (a data 
object) in the electronic file of the patient, provided by 
the card 2. By definition, this object is of a non-resident 
type and consequently is automatically indexed in the remote 

database 12. During the process, the system depersonalizes 
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the data object (and optionally encrypts the object for 
example insofar as the country regulations allow it) , 
identifies the object by a random anonymous reference 
provided by a certificate as hereinabove explained, and 
transmits the (encrypted) object via the network 10 to the 
database server 8 where the data object is stored among the 
data objects belonging to other persons. The anonymous 
certificate generated as a result of this transaction is 
stored in the card 2 of the patient with a transaction 
descriptor, for example the type of prescribed laboratory 
examination "Blood formula of June 2, 1999", the eventual 
result of the examination being the indexed data, or yet a 
descriptor defining an image "Identification photo of the 
patient, April 15, 1999", the indexed data being the photo. 

The certificate stored in the card 2 is the unique 
identifier allowing the data object to be meaningfully 
retrieved in the database 12. The patient can transfer a copy 
of the certificate or preferably a certificate derived 
therefrom to the card (not shown) of a third party as the 
healthcare practitioner, so as to authorize the practitioner 
for having access to the data object at a later time, e.g. 
when the laboratory results will be available. The management 
of this authorization (the derived certificate) is achieved 
by a process integrated in the operating system of the card 
of the practitioner (or the index cards in general unless 
such a feature is only needed for a given type of users) . 

Thereafter, the holder of the certificates will have 

access to the associated data objects as follows (scenario of 

a simple transaction involving non-resident objects) . The 

application executed by the computer 4 requests the reading 

of the descriptor of an index to the operating system of the 

authorized card (OS of a real card or OS of a virtual card) . 

The index contains a set of certificates referring to data 

objects. The operating system of the card returns the index 

37 



WO 00/26866 



PCT/CA99/01011 



information except a number of confidential variables like, 

among other things, the certificates of the indexed data 

objects. The application returns the descriptors of the 

transaction for which the corresponding indexed data objects 

are required to the operating system of the card. Upon 

receiving the descriptors, the operating system of the card 

communicates with the server 8 of the database (s) 12 whose 

address is specified in the index of the card. In the 

transaction, the operating system of the card includes the 

certificates relative to the data objects. These certificates 

can be encrypted and/or derived to prevent security leaks . On 

the remote site, the server 8 of the database 12 searches the 

objects corresponding to the certificates and returns them to 

the requiring site. The exchange preferably involves the use 

of security protocols for identifying the involved entities 

in the transaction along with security protocols associated 

to the confidentiality, the integrity and non repudiation of 

the transaction. Once the objects are received, the operating 

system of the card makes the information readable 

(decryption, etc.) and returns it to the application. 

The following description provides a typical scenario 

for using the indexing device 7 0 for the virtual card memory 

generation for an IC card 2 . 

In- the case where the application requires the storage 

of data in the card 2 and that the memory space of the card 2 

is insufficient, the operating system of the card 2 activates 

itself the indexing process for generating the virtual 

memory. The operation is about the same as previously 

described. The fundamental difference resides in the fact 

that it is the operating system of the card 2 that takes the 

initiative of performing a data indexing. In the case where 

the request is made to the card 2 for obtaining the 

information (which is supposed to be in the card) , the 

operating system of the card will retrieve the data objects 
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that it has transferred to the database 12 on the remote site 

in a transparent manner to the user. The application 

generates a request for storing an object on the card 2. The 

operating system of the card 2 verifies the available memory 

space, determines whether the requested space is 

insufficient, and verifies whether it is possible to 

establish a network connection with a remote site (directory 

search) . If no network connection is possible, the 

transaction is aborted . If a network connection is possible, 

the operating system of the card 2 verifies the attributes of 

the objects stored in the card 2 to detect those that it can 

transfer and selects the objects according to different 

algorithms, like the less used objects, the largest size 

objects, etc. Afterwards, the operating system of the card 2 

15 generates or obtains a global reference for the group of 

selected objects and stores it in a system index in the card 

2 (which is not available to the world outside the card 2) 

with a set of relevant information. The operating system of 

the card then transforms the data objects in a monolithic 

2 0 binary block and transfers it in a secure fashion toward the 

database 12 that it has selected. It is somewhat like if the 

operating system of the card 2 would carry a memory page. It 

should be noted that neither the certificates nor the address 

of the_selected database 12 (in the case where there are 

25 several) are known to the world outside the card (e.g. the 

applications) . When the data objects are requested by the 

application, the operating system of the card 2 searches in 

the database 12 in a transparent fashion, and delivers the 

requested objects to the application. 

The operating system of the card 2 can also use another 

strategy to recover memory space: it can proceed with a 

screening of the card » s obj ects , i.e. transfer to the 

database 12 of the occurrences of the object classes that are 

no longer active, including indexes, e.g. the thirty-day and 
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older pharmaceutical prescriptions. The process is the same 
as for the virtual memory generation. In this case, the 
operating system of the card 2 adds summary information to 
the index or to the zone of purged data regarding the 
existence of other occurrences of objects. 

In the case where there is no available network, the 
operating system of the card 2 cannot use the indexing device 
70, unless it temporarily saves the information r locally, 
which is not recommended since the availability of the 
working station is not guaranteed and for security reasons. 
However, it is possible to temporarily and safely store a 
transaction in a securised server with a SAM when applicable. 
Such a server provides a safe link between several points of 
service and the network servers 8 (BDA, etc.). Likewise, if 
the network is unavailable, it is not possible to have 
reading access to remote objects, including memory pages of 
the virtual memory. 

While embodiments of this invention have been 
illustrated in the accompanying drawings and described above, 
it will be evident to those skilled in the art that changes 
and modifications may be made therein without departing from 
the essence of this invention. All such modifications or 
variations are believed to be within the scope of the 
invention as defined by the claims appended hereto. 
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WHAT IS CLAIMED IS: 

1. A method of securely expanding a storage capacity of 
a memory of an IC portable device, comprising the steps of, 
for a data object stored or to be stored in the memory of the 
IC portable device: 

randomly generating a unique master certificate used as 
a descriptor of the data object; 

indexing the master certificate in the memory of the IC 
portable device; 

deriving a secondary certificate from the master 
certificate, the secondary certificate being determinable 
only using the master certificate; 

storing the data object with the secondary certificate 
on a data storage medium external to the IC portable device; 

whereby the memory of the smart card is freed from the 
data object as the data object is stored on the data storage 
medium, thereby securely expanding the storage capacity of 
the memory of the IC portable device as only the IC portable 
device has key information to retrieve the data object stored 
on the data storage medium. 



2^ The method according to claim 1, comprising the 
additional step of : 

attaching a descriptive label to the master certificate, 
the descriptive label representing a character of the data 
object; 

and wherein: 

the descriptive label is indexed with the master 
certificate in the memory of the IC portable device. 
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3. The method according to claim 1, comprising the 
additional step of : 

encrypting the data object prior to the storing step, 
the data object stored on the data storage medium being 
5 encrypted. 

4. The method according to claim 1, comprising the 
additional steps of: 

randomly generating a data access authorization 
certificate derived from the master certificate and with 
which the secondary certificate is determinable; and 

storing the authorization certificate in an IC portable 
device held by a third party, 

whereby the data object stored on the data storage 
medium is retrievable with the IC portable device of the 
third party. 

5. The method according to claim 4, wherein: 
the authorization certificate is transmitted to the IC 

portable device held by the third party via a secured 
communication channel using a cryptographic protocol. 

6. The method according to claim 4, wherein: 
the authorization certificate is stored in the IC 

25 portable device held by the third party through a secured 
communication channel with the IC portable device from which 
the master certificate originates. 

7. The method according to claim 4, comprising the 
30 additional step of: 

attaching a trigger, to the authorization certificate, 
the trigger carrying authorization use instructions for the 
IC portable device held by the third party. 
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8. The method according to claim 7, wherein the 

instructions are selected among a life duration of the 

authorization certificate, a service location restriction, a 

5 third party class restriction, and a transitive authorization 
control . 

9. The method according to claim 1, wherein the 
certificates are managed by a secured microprocessor card 

10 server. 

10. The method according to claim 1, wherein the master 
and secondary certificates are generated using a 
cryptographic algorithm. 
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11. The method according to claim 1, comprising, prior 
to the generating step, the additional step of: 

inputting the data object into a secured temporary 
memory in response to a software application request. 



12. The method according to claim 1, wherein: 

the IC portable device comprises a database of actions 
in relation with conditions associated thereto, and triggers 
that trigger execution of each action for which the 
25 associated condition is met. 

13. The method according to claim 1, wherein: 

the data storage medium is connected to a server 
comprising a database of actions in relation with conditions 
associated thereto, and triggers that trigger execution of 
each action for which the associated condition is met. 

14. The method according to claim 13, wherein: 
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the database comprises a truth table including the 
conditions and the actions related thereto. 



15. The method according to claim 1, comprising the 
additional step of: 

attaching a trigger to the master certificate indexed in 
the memory of the IC portable device, a predetermined action 
being executed in relation with the data object associated to 
the master certificate when the trigger meets a predetermined 
condition. 

16. The method according to claim 1, comprising the 
additional step of: 

attaching a trigger to the data object stored in data 
storage medium, a predetermined action being executed in 
relation with the data object and the master certificate when 
the trigger meets a predetermined condition. 

17. The method according to claim 1, wherein: 

the secondary certificate corresponds to a cell address 
on the data storage medium where the data object is stored. 

18. The method according to claim 17, wherein: 

the data storage medium is provided with a concordance 
table or a function between the secondary certificate and a 
corresponding memory address in the data storage medium. 

IS. The method according to claim 1, wherein: 

the data object stored on the data storage medium has a 

structure comprising a pointer to an additional data object 

stored on the data storage medium. 



20. The method according to claim 1, wherein: 

44 



WO 00/26866 PCT/CA99/0101 1 

the certificates are generated by the IC portable 
device . 

21. The method according to claim 1, wherein: 

the master certificate remains at all time in a secured 
memory zone distinct from the data storage medium. 

22. The method according to claim 21, wherein: 

the secured memory zone is in the memory of the IC 
portable device. 

23. The method according to claim 1, wherein: 

the IC portable device has a unique key identifier, and 
the master certificate is generated from the key identifier. 

24. The method according to claim 1, wherein: 

the data storage medium has a unique reference domain 
identifier and is provided with a central certificate 
generator, the master certificate being randomly generated, 
from the unique reference domain identifier, by the central 
certificate generator, and transmitted to the IC portable 
device via a secured link. 

25_. The method according to claim 1, wherein: 
the data storage medium is a data warehouse. 

26. The method according to claim 2, wherein the 
descriptive label relates to a health care type of service. 

27. The method according to claim 4, wherein: 
the third party is a doctor. 
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28. A method of operating an IC portable device having a 
memory for storing data objects, comprising the steps of: 

detecting a predetermined condition relative to the 
memory of the IC portable device; and 

if the condition is detected, applying the method 
according to claim 1 on a number of the data objects stored 
in the memory of the IC portable device. 

29. The method according to claim 28, wherein: 

the condition is a saturation level of the memory of the 
IC portable device. 

30. The method according to claim 28, wherein: 

the condition is an express request to free the memory 
of the IC portable device. 

31. The method according to claim 28, wherein the step 
of applying the method according to claim 1 is executed only 
on the data objects having a mobility property indicating 
that the data objects are moveable outside the memory of the 
IC card device. 

32. The method according to claim 31, comprising the 
additional steps of: 

assigning the mobility property to each data object 
based on a character thereof; and 

assigning a location attribute to each data object, the 
location attribute being set to a resident state for each 
data object stored in the memory of the IC card device and 
set to a non-resident state for each data object stored 
outside the memory of the IC card device. 
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33. The method according to claim 28, comprising the 
additional steps of: 

assigning a mobility property to each data object based 
on a character thereof, the mobility property indicating that 
the data object is moveable outside the memory of the IC card 
device; 

assigning a location attribute to each data object, the 
location attribute being set to a resident state for each 
data object stored in the memory of the IC card device and 
set to a non-resident state for each data object stored 
outside the memory of the IC card device; and 

assigning an authorized residence period in the IC 
portable device to each data object based on the character 
thereof ; 

and wherein the step of applying the method according to 
claim 1 is executed on: 

a number of the data objects having the location 
attribute set to the resident state, the mobility property 
indicating that the data object is moveable, and the 
residence period elapsed when there remains a predetermined 
amount of space in the memory of the IC portable device; 

on parts of the data objects having the location 
attribute set to the resident state, the mobility property 
indicating that the data object is moveable, and regardless 
25 of the residence period when the IC portable device is short 
or expects to be short of free memory space; and 

on whole ones of the data objects having the location 
attribute set to the resident state regardless of the 
residence period when the IC portable device is short of 
memory to carry out an operation. 
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34. The method according to claim 33,, comprising the 
additional steps of: 
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assigning a use attribute to each data object, the use 
attribute being set to an active state when the data object 
is solicited, an inactive state when the data object remains 
unsolicited for a predetermined time period, and an archive 
state when the data object is archived on the data storage 
medium; and 

archiving each data object having the location attribute 
set to the non-resident state and the use attribute set to 
the inactive state for a predetermined inactive time period 
or. the data storage medium. 

35. The method according to claim 34, wherein: 

the memory of the IC portable device comprises non- 
resident object indexes storing the master certificates of 
the data objects stored on the data storage medium, a 
resident object index storing references to the data objects 
having the location attribute set to the resident state and 
subjected to a forced indexing, a master index storing a 
unique key identifier of the IC portable device, and a class 
index storing a list of classes of the data objects subjected 
to a forced indexing. 

36. The method according to claim 35, wherein: 

the memory of the IC portable device comprises an index 
storing references to nominative files located in remote 
sites . 

37. The method according to claim 35, wherein the non- 
resident object indexes are data objects to which the method 
according to claim 1 is also applicable. 

38. The method according to claim 28, wherein: 
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each master certificate is a data object to which the 
method according to claim 1 is also applicable. 



39. The method according to claim 28, wherein: 

5 the IC portable device has an object dictionary 

containing object class definitions including directives and 
methods for the data objects; 

and the method comprises the additional step of 
classifying each data object in relation with the definitions 
10 in the object dictionary. 

40. The method according to claim 39, wherein: 

the class definitions include a priority qualifier 
determining a data object indexation priority order for 
15 applying the method according to claim 1. 
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